The following abbreviations are herewith defined, at least some of which are referred to within the ensuing description of the prior art and the present invention.    ARP Address Resolution Protocol    CPU Central Processing Unit    MAC Media Access Control    IP Internet Protocol    ISER Integrated Site Edge Router    RFC Request For Comments    VLAN Virtual Local Area Network    VRI Virtual Router Instance    VRID Virtual Router Identifier    VRRP Virtual Router Redundancy Protocol
Referring to FIG. 1 (PRIOR ART), there is illustrated an exemplary Ethernet network 100 which is used to help describe VRRP and one problem associated with implementing VRRP that is addressed by the present invention. In this example, the Ethernet network 100 includes two physical routers, R1 and R2. Assume, R1 has IP address 192.32.15.1/MAC of 00:00:A2:0B:00:01 and R2 has IP address 192.32.15.2/MAC of 00:00:A2:BE:D0:03. R1 backs-up R2 and vice-versa. Therefore, R1 and R2 each have two VRRP virtual routers in this example: virtual router V1 with IP address IP(V1)=192.32.15.1, VRID of 37, and virtual router V2 with IP address IP(V2)=192.32.15.2, VRID of 73. Plus, virtual router V1 has a VRRP MAC address of MAC(V1)=00:00:5E:00:01:25 (VRID 37, Hex 25), and virtual router V2 has a VRRP MAC address of MAC(V2)=00:00:5E:00:01:49 (VRID 73, Hex 49).
As shown, R1 has V1 which is currently the “master” and is a part of a virtual router instance VRI-1. And, R2 has V1 which is currently the “backup” and is also a part-of the virtual router instance VRI-1. Both of the V1's form what is known as VRRP Group V1=37 (recall the VRID of 37). Likewise, R1 has V2 which is currently the “backup” and is a part of a virtual router instance VRI-2. And, R2 has V2 which is currently the “master” and is also a part of the virtual router instance VRI-2. Both of the V2's form what is known as VRRP Group V2=73 (recall the VRID of 73). In the Ethernet field, there can be at most 255 VRRP groups per Ethernet VLAN because all VRRP routers (including V1 and V2) have a common MAC address of the format 00:00:5E:00:01:XX where the last octet (XX) is the VRRP group identifier (i.e., the highest hex FF in the last octet corresponds to the highest 255th VRRP group). The limited number of 255 VRRP VRIs (or VRRP groups) that can be used in the Ethernet network 100 is one of the problems that is addressed by the present invention (note: in all of the examples shown and discussed herein it should be appreciated that each VRI has its own VRRP group).
In this example, R1 is the master for V1 because it is the IP address owner (recall both R1 and V1 have the same IP=192.32.15.1). Thus, R1 periodically sends VRRP advertisements with the source MAC address set to its VRRP address (MAC(V1)=00:00:5E:00:01:25) and the destination set to an Ethernet multicast MAC address 01:00:5E:00:00:12 (this address is established by the standards). The backup for virtual router V1, in this case R2, registers to monitor the Ethernet multicast MAC 01:00:5E:00:00:12 and listens passively to the transmitted VRRP advertisements. If the link 102 to R1 fails (or R1 itself fails), then R2 will not receive the VRRP advertisements and will take over as the “master” for VRRP group V1 and act as the active router for V1 (i.e., V1's VRRP state machine transitions from “backup” to “master” in R2)(see the link failure scenario shown in FIG. 2).
Host H1 is configured to use a default router IP address which in this example is IP(V1). As such, when H1 initializes it sends out an ARP request to its configured default router IP(VL) 192.32.15.1. The physical router R1 which is the master for V1 receives this ARP requests and responds with the MAC address of V1, the VRRP MAC(V1)=00:00:5E:00:01:25 (this assumes the link 102 or R1 have not failed). Host H1 updates its ARP cache with this MAC(V1)=00:00:5E:00:01:25. Now, later when host H1 wants to talk to host H13 (for example) on another subnet (not shown), it sends a packet with the source MAC address set to MAC(H1), the destination MAC address set to MAC(V1), the source IP address of IP(H1), and the destination IP address of IP(H13). Router R1, which is currently the master for V1, receives this packet and forwards it to another interface to be forwarded through a common cloud 102 to H13 (this scenario is shown in FIG. 1—no fault). If the link 102 to R1 fails (or R1 itself fails), host H1 need not make any changes; the packet is simply forwarded to H13 via R2 in a manner that is completely transparent to H1 (see FIG. 2—the link fault scenario when R2 becomes the “master” for VRRP group V1 after it does not receive VRRP advertisements associated with V1 from R1 and R1's V1 and V2 both transition to “initialization”)(note: if R1 itself failed then R1's V1 and V2 would not transition to “initialization” instead they would not work). Once, the failure of link 102 to R1 is resolved then R1 will become the “master” and R2 reverts to being the “backup” for V1 (these state transitions also take place if a failure to R1 itself is resolved). Again, H1 will not be aware of any of these changes. Similarly, the same can be said about host H2 and its default router IP(V2). If a link to Router R2 (the master for the VRRP group V2) fails (or R2 itself fails), then R1 takes over the mastership of the VRRP group V2. Host H2 does not need to make any changes when this happens.
Now when the link 102 to R1 fails (or R1 itself fails), then during the time it takes R2 to detect this failure by not receiving the VRRP advertisements and during the time it takes R2 to become the master for V1 all of the packets which where sent by host H1 are going to be lost. So, to keep the packet loss at a minimum this down time should be kept as small as possible. For instance, VRRP as discussed in the RFC 3768 requires this detection time to be completed in seconds (see RFC 3768 “Virtual Router Redundancy Protocol (VRRP)” dated April 2004—the contents of which are incorporated by reference herein). This multi-second time delay is not necessarily desirable. Thus, a relatively new router which is known in the field as an ISER has been developed to implement a variant of RFC 3768 which can switch traffic received from one or more hosts to a backup router in less than 200 milliseconds.
Unfortunately, Ethernet networks with routers R1 and R2 that implement either the multi-second VPPR or the sub-second VPPR still have a problem because of the limited number of 255 possible VRRP groups per Ethernet VLAN (recall that 255 is set due to the last octet (XX) in the common VRRP MAC address 00:00:5E:00:01:XX). This is a problem since routers R1 and R2 can often support many VRI's (e.g., more than 500 VRIs) but only 255 of those VRIs can be VRRP VRIs (which support VRRP). Thus, it would be desirable if all of these VRIs could implement VRRP where in the event of a failure then all of the VRIs can re-direct traffic away from the “master” router towards the “backup” router. This need and other needs are satisfied by the passive VRRP solution of the present invention.